IBIS Macromodel Task Group Meeting date: 11 April 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Mike LaBonte to post Walter's BIRD 166.1 proposal and presentation. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Michael M.: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow BIRD: - Discussion: Arpad asked for clarification on a point Ambrish had made at the previous meeting. Ambrish said his point had been that Walter's BIRD 166.1 fixes today's flow, while changes proposed by Fangyi affect the IR matrix passed to Init(), but would not change the flow. Arpad again said that he wanted to ensure that if we accepted the BIRD166.1 proposal it would be an incremental step, and we could add Fangyi's proposed changes later to get time domain working without having to backtrack on any BIRD 166.1 changes. Walter noted that in his proposal and Fangyi's the final IR input to the Rx2 Init() was the same, but Fangyi's proposal included some additional outputs from the Rx Init() functions. He also said that our time domain flow was already working because the output of Rx1's GetWave() is passed to Tx2's, and the output of Tx2's is convolved with the IR of channel 2 and passed to Rx2's GetWave(). Therefore, everything is accounted for at Rx2's GetWave(). Fangyi said the issue is with Init() processing, even for a bit-by-bit GetWave() flow. Arpad asked if our flow was okay for a pure GetWave() only flow. Fangyi said no, even for GetWave() flow the AMI model for the Rx may optimize its tap settings in Init(). He said Init() has two effects, one might be to change the IR if it supports Init only flow, but the other could be to initialize internal settings, optimize, choose tap weights, etc. An Rx might have DFE, for example, and not return an IR from its Init() but still use the IR input to Init() to decide on its taps. Walter described a scenario in which none of the AMI_Init() functions returned an IR. In this scenario, the input to the Rx2 Init() would only contain the the upstream channels and none of the upstream equalization effects. In this scenario, if the Rx were doing its optimization of the DFE taps in Init(), then even the time domain flow is broken. He noted that this had always been broken, and that workarounds had been presented in a DesignCon paper. He noted that even a regular flow (no repeater) was subject to this flaw. Fangyi asked how this could occur in a regular flow. Walter said that if the Tx were GetWave() only, and if the Rx optimized its tap weights in Init() and not in GetWave(), then the same problem existed. Fangyi said that would be a Tx model problem, not a flow problem. Ambrish objected to Fangyi's characterization of the GetWave() only Tx as a "model problem," and said the spec allows a Tx model to be GetWave() only. Bob Miller noted that he had produced Rx models that behaved as Fangyi and Walter had described. These models do not return an IR from Init() (i.e. "GetWave() only"), but their Init() functions expect IRs that represent everything in front of them, and they generate the tap weights accordingly. The GetWave() flow then uses the tap weights set during Init(). This led to a discussion about dual-mode models vs. Init Only vs. GetWave Only. Arpad asked if we needed to tighten up the spec to ensure that simulations would produce the right results when models from different vendors were mixed. Walter and Fangyi felt that ideally the models should be dual mode. Ambrish acknowledged that there were certain limitations if a model did not provide some approximation of its behavior in a modified IR returned by Init(), but he objected to any sort of mandate for dual mode models. He said that dual models caused confusion for some users when Init() flow and GetWave() flow provided different results. He did not think the solution was to mandate that a model handled equalization in the Init() and GetWave() (dual mode). He noted that the spec currently warns against issues that can occur when mixing models of various types. Walter agreed with Ambrish that the spec shouldn't mandate dual mode models. Returning to Arpad's original question, Walter said that he felt his proposal would not interfere with Fangyi's. He said there could still be problem scenarios, but these were pre-existing. Arpad noted a comment from Vladimir that we should be very clear that BIRD 166.1 is only talking about statistical flow. Walter said he thought this was already implied, but he was open to any suggestions for modified wording. Fangyi said he was not sure BIRD 166.1 was compatible with his proposal. He noted that it still did not provide the IR from Rx1 to Rx2 so it still did not handle crosstalk, and it was unclear how it would extend to cascaded redrivers. Walter noted that he had suggested one additional change to Fangyi's proposal, passing the Tx Init() two IRs, one which was the output of the redriver Rx Init(), and one which was the downstream channel. Walter said if this were done it would resolve the crosstalk issues entirely. Fangyi said this led to the question about how it would extend to cascaded redrivers. In a two-repeater system, what would be the input to Tx2? Walter said Tx2 would get the output of Rx2 Init(), which contained everything upstream, and also the IR of the downstream channel. Walter said the IR representing the downstream channel would only be for the next channel, not all subsequent channels, because all we needed was the information to get to the next Rx. He noted that the very first Tx in the chain would only get the one IR representing the immediate downstream channel. Fangyi asked why, even in a single repeater case, the initial Tx stopped at the first Rx? Why wouldn't the initial Tx want to optimize the entire channel? Walter said this got into back channel and optimizing everything together. Fangyi said in theory any Tx and Rx could communicate (via backchannel) to optimize, but in reality all of the redrivers ran on fixed set-ups and did not optimize. Walter said in that case it was academic and the BIRD 166.1 flow worked. He said one might in theory have a complicated system in which the primary Tx wants to optimize based on what's happening at the terminal Rx, but silicon doesn't do that. Fangyi said perhaps that's actually where backchannel should happen, between the terminal Tx (initial Tx) and the terminal Rx. Walter noted that in some cases (DDR5) the Tx on the controller is optimizing the Rx, not the Rx optimizing the Tx as we often think of it in backchannel discussions. Fangyi said this raised another fundamental issue with AMI, we always call Tx Init() first. Walter noted that we may need another BIRD to add iterative AMI_Init() sequences or some other method to allow every Tx and Rx to communicate. He noted that BIRD 147.6 had been dramatically simplified and only contained iterative backchannel calls during GetWave(). - Arpad: I'd like to encourage everyone to look over the proposal again to see if we can come to a decision on this BIRD draft. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 18 April 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives